Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/015a/dosimp10.zip/SIMPLY3.HYP

Text File | 1991-08-12 | 105KB | 1,906 lines

                            The |TAPPEND|T Command

This command is a TSR that works just like the PATH command, only for
data files instead of executable files.  If your current directory is
C:\WORD and you want to do something with the file C:\WORD\LETTER.DOC,
that's easy.  You just say LETTER.DOC.  But if C:\WORD is not the |ncurrent|n
|ndirectory|n, then you have to say \WORD\LETTER.DOC in order to access that
file.  Well this is no longer the case, ever since the |nAPPEND|n command
came on the scene in DOS version 3.2.  If you had previously issued the
command |nAPPEND|n C:\WORD then you can just say LETTER.DOC, no matter what
your |ncurrent|n |ndirectory|n is, and DOS will be able to find the file.

There is a big problem with this though.  DOS can use the |nAPPEND|n method
to find the file, but it can't use it to write the file back to disk.  So
if any changes are made to the file after it has been found via the AP-
PEND method, the new copy of the file will be written into the |ncurrent|n
|ndirectory|n.  The original copy of the file is still right where it was,
only without today's changes.  Now if you make some more changes to the
file tomorrow, and you had started from some other |ndirectory|n, then by the
                           <page down> for more
                             APPEND continued
end of tomorrow you'll have three copies of your LETTER.DOC file sitting
on your disk, but all three of them are incomplete.  You still have the
original copy in the C:\WORD directory, but it is missing yesterday's and
today's changes.  Then you have the copy that was created yesterday, that
has yesterday's changes but not today's changes.  And finally you have
today's copy, which is the original with today's changes, but not yester-
day's changes.  Three copies of the same file, in three different direc-
tories, and all of them are wrong.  So what's so great about the |nAPPEND|n
command?

Well it does have its uses, but you just have to think for a minute about
what you're doing, before you use it.  First, you'll need to find out for
sure which files on your disk ever get modified.  See, you're not the on-
ly one who ever modifies your files.  Your programs do some modifying of
their own files from time to time.  So to find out, do a complete BACKUP,
which turns off the Archive attributes for all your files, then use your
computer normally for a couple weeks, and then do this:
          |nATTRIB|n \*.* /S || |nFIND|n " A " > |nPRN|n
                           <page down> for more
                             APPEND continued
That will send, to your printer, a list of every file on the disk that
has been modified since the backup.  (See the sections on ATTRIB, FIND,
Redirection, and PRN to find out how it works.)  Make sure to leave a
<Space> on each side of the A inside the quotes, or it won't work.

You never want to put the directories that contain these changeable files
on your |nAPPEND|n command line.  But you can use it for any directory that
doesn't contain changing files.  Suppose you keep all your word procces-
sor's program files in your C:\WORD |ndirectory|n, and you keep all the doc-
uments that you create with your word processor, in a subdirectory called
C:\WORD\DOCS.  Suppose also that none of the files in your C:\WORD direc-
tory came up on that list of changeable files.  Then you can put the C:\
WORD |ndirectory|n on your PATH, and also on your |nAPPEND|n line.  And you can
change to your C:\WORD\DOCS |ndirectory|n (with the CHDIR command) before
each time you start your word processor.  This way, all the files you
might change with the word processor are in the current |ndirectory|n, so
they'll get written back to the proper place, but you can still access
the word processor's executable files (via the PATH) and it can access
its |soverlay|ss (via the |nAPPEND|n line), and everybody will be happy.
                            The |TASSIGN|T Command

Here's a command you won't be using too often.  It is a TSR that is used
to change all references to one drive, to another drive.  This is useful
for installing programs that insist on being installed from a disk in
drive A:.  Well, what if you got the software on 3.5" disks, and your
3.5" drive is drive B:?   Here's where the |nASSIGN|n command comes in.  If
you were to issue the command |nASSIGN|n A=B then every time the installation
program requests a read from drive A:, DOS will send the program to drive
B: instead and you will probably be able to install that software without
any trouble.

This command is not all roses, though.  It can be very dangerous!  Don't
use it unless you have a complete backup of your hard drive as well as any
floppies you may be using while the |nASSIGN|n command is in effect.  Then,
disable the assignment just the second you're done with whatever you were
doing that required the assignment.  To do that, just enter |nASSIGN|n with
no parameters.

                           <page down> for more
                             ASSIGN continued
That really is not just hot air.  Don't leave an assignment active for
one single minute longer than you have to.  All sorts of terrible things
can happen.  Some DOS commands or programs might ignore the assignment,
and perform the specified command on the A: disk when you meant for the
command to happen to the B: drive.  On the other hand, if you forget that
you have an assignment made, and perform some command that does not ig-
nore the assignment, you'll end up once again having that command per-
formed on the wrong disk.  For example, what if after you've given the
command |nASSIGN|n A=C, then you forget that you've done that, and put a disk
into drive A: and enter |nDEL|n A:*.*?  Know what's going to happen?  All the
files in the current directory of drive C: will be deleted.

And any TSR that is resident while an |nASSIGN|n is active, including DOS's
PRINT command, can do some serious damage to your data.  And if you goof
up and use DOS's BACKUP command on an assigned drive, it might act like
it's working, but when you go to RESTORE the |nbackup|n disks, you may find
that your |nbackup|n |ndisks|n are worthless.

                           <page down> for more
                             ASSIGN continued
If for any reason you find that you need to use the |nASSIGN|n command on a
regular basis to make one particular application work with your setup, do
it from a batch file.  Have the |nbatch file|n make the assignment, then run
the app, and then undo the assignment.  That way you'll never forget to
unassign, because the |nbatch file|n always remembers for you.

If you already have one assignment made, and you issue another |nASSIGN|n
command to make another assignment, the second one will cancel the first
one.  But you can make two assignments with one |nASSIGN|n command, so that's
ok.  Just do something like |nASSIGN|n A=C B=C.

Notice that this command is one of the only times where you are supposed
to reference a drive letter without using a colon (:).  |nASSIGN|n A=B is
correct, but |nASSIGN|n A:=B: is not.

If you have DOS version 3.1 or later, use the SUBST command instead of
|nASSIGN|n.  It's not the safest command in the world either, but it's sure
safer than |nASSIGN|n!  If you have the |nSUBST|n command you should just delete
                           <page down> for more
                             ASSIGN continued
the |nASSIGN|n.COM file from your hard drive so you don't forget and use it.

DOS version 5 adds the /STATUS switch to this command.  If you enter the
command |nASSIGN|n /STATUS then DOS will tell you what ASSIGNments you've
made, that are still active.














                             The |TBREAK|T Command

Here's a command that's not used very often.  What it does, is to turn
break checking on and off.  The default is off, so the only time you need
to use it is to turn it on, or to turn it off if you'd previously turned
it on.

So what is break checking?  Well you can press the <Ctrl-Break> keystroke
combination to break out of a program that's running, if you decided you
didn't want to do it after all, or if it seems that something in the pro-
gram has gone wrong.  Well if break is off, then DOS will only look to
see if you have pressed <Ctrl-Break> each time an I/O operation is
performed.  That means when the program is looking for input from the
keyboard or serial port, or when the program is sending output to the
screen, printer, or serial port.  However, if break is on, then DOS will
check the |nkeyboard|n buffer for a <Ctrl-Break> keystroke every single time
the program makes any DOS function call.  This includes when the program
is writing to disk, and all sorts of things.  To put it simply, |nBREAK|n ON
makes it so that you can break out of a program a lot more easily, but of
                           <page down> for more
                              BREAK continued
course it slows your system down because DOS has to take time to check
the keyboard buffer a lot more often.  Another bad thing about having
|nBREAK|n on is that if you break out of a disk write, that disk's FAT can
get trashed.

|nBREAK|n OFF puts the break setting back to normal, which means that break
checking will occur more seldom and the system will not be slowed down
by checking for break so often.  The command |nBREAK|n all by itself, with
no on or off parameters, will just report the |ncurrent|n state of break.

All this applies to the <Ctrl-C> keystroke combination as well.  It's
basically the same thing.

This command can also be used in the CONFIG.SYS file if desired.  In
which case you use an equals sign (=) between the command and the para-
meter, as in BREAK=ON.  Of course BREAK=OFF would never be needed in the
|nCONFIG.SYS|n file because |nBREAK|n is always off every time you reboot, until
such time as a |nBREAK|n ON command is issued.

                            The |TBUFFERS|T Command

This command can only be used in your CONFIG.SYS file.  It tells DOS how
many disk buffers to set up if you don't want to use the default.  A disk
buffer is just like a very small cache with no look-ahead.  So if you're
using a disk |ncache|n, you want to use a very small number of buffers, such
as 5.  (Certainly not 0, though.)  If not, use the largest one that the
installation manuals for your applications say.  If one manual tells you
that app needs 25, and the manual for another app says 30, then use 30.

The syntax for the |nBUFFERS|n command is like this:
          BUFFERS=AA,BB /X
The "AA" parameter in that example, is the number of buffers DOS should
set up.  Each buffer takes 528 bytes of memory, to store 512 |nbytes|n of
disk data.

If you're using conventional or high |nmemory|n for the buffers, you can have
anywhere from 1 to 99 of them.  If you have a DOS version earlier than
3.3, the |ndefault|n is 2.  If your DOS is 3.3 or later, then your |ndefault|n
                           <page down> for more
                             BUFFERS continued
number of buffers depends on your hardware.  If you have more than 256K
of RAM, then it's 10.  Or if you have over 512K, it's 15.

If you have DOS version 4.0 or later, then you can use the BB parameter
in that example to specify the number of look-ahead sectors.  (See the
section on Cache for what that means.)  This parameter is optional, but
if you want any look-ahead sectors, you can use anywhere from 2 to 8, and
they each take up 512 bytes of |nRAM|n.  If you're using a real disk |ncache|n,
then leave this parameter at the default, which is no look-ahead.

Another thing you can do, but only if you have DOS version 4, is to place
your buffers into expanded memory if you have it, to keep them from using
up your conventional |nmemory|n.  Of course if you do that, you have to put
the BUFFERS= line in your CONFIG.SYS file later than the line that loads
your |nexpanded|n |nmemory|n manager.  Anyway, |nexpanded|n |nmemory|n is what the /X
parameter is for in the |nBUFFERS|n command.  And you are allowed up to ten
thousand of them, instead of the normal limit of 99.

                           <page down> for more
                             BUFFERS continued
Now in DOS version 5.0, if you have one meg of RAM so that you can load
DOS into the High Memory Area, then the buffers go up there too, with the
rest of the DOS kernel.  That is, if there is room for all of them.  See,
if you specify a number so large that they can't all fit up there the way
it is, like 46 for example, there is one small section of the DOS kernel
that can come back down to conventional |nmemory|n to allow that huge chunk
of buffers to go |nhigh|n.  Or if you use an even larger number, like 50, so
that they won't fit up there even with that little piece of DOS coming
back down, then the buffers will all stay in |nconventional|n |nmemory|n.  But if
you specify just the right amount, like 36 to 44 (it differs on different
computers), then all of the buffers can go |nhigh|n, and all of the DOS ker-
nel can stay |nhigh|n too and you don't lose a byte of |nconventional|n |nmemory|n,
whether you use that large number of buffers, or a low number like 5.

Anyway, once you get up over 40 buffers, it takes DOS about as long to
search all those buffers for the required data as it would to just get it
from the hard drive, so having that many buffers can actually slow your
system down.
                           <page down> for more
                             BUFFERS continued
The reason for trying to keep the number of buffers low in earlier ver-
sions of DOS, was to save memory.  But since in DOS 5, you can specify a
much larger number of buffers without eating up a speck of conventional
|nmemory|n, there's no reason to keep the number low anymore.  Remember that
for DOS to access a cache in expanded |nmemory|n, that involves a transfer
across the data bus, which is slow, and to access a |ncache|n in extended
|nmemory|n, that involves the CPU switching into protected mode, which is
slow, but for DOS to access buffers in the high |nmemory|n area, no slowdown
is involved.  Therefore, it is no longer quite so sensible to have a low
number of buffers just because you're using a disk |ncache|n.  Because access
to the data in the buffers will be faster than access to the |ncache|n.  Be-
sides, since caches monitor what data stays in the |ncache|n when it starts
to overflow, it's possible that some data which is not requested often
enough for the |ncache|n to hold it, might be in the buffers because the
buffers only keep the most recently-read info, not just the most fre-
quently requested info.  So since nothing else besides the DOS kernel
and the buffers can go into the |nHigh|n |nMemory|n Area if DOS is using that
space, you may as well fill that space up with buffers if you feel like
it.
                             The |TCALL|T Command

This is a batch file command, which has almost no use at the DOS prompt.
It only exists in DOS versions 3.3 and later.  Before that, it was neces-
sary to use the COMMAN|1D command to accomplish the same thing.  What it
does is to run another |nbatch file|n from within a |nbatch file|n, and still re-
turn to the calling |nbatch file|n after the called |nbatch file|n is completed.

Usually if you run one |nbatch file|n from within another one, when the sec-
ond one finishes it just gives you back a DOS |nprompt|n, without ever re-
turning to finish the rest of the |nbatch file|n from which it was run.  The
|nCALL|n command takes care of that problem.

Another thing about the |nCALL|n command is that if ECHO was off in the call-
ing |nbatch file|n, then |nECHO|n will remain off in the called |nbatch file|n.  So
the second one doesn't have to have |nECHO|n OFF as its first line.  But if
you want |nECHO|n to be on in the called |nbatch file|n, then its first line has
to be |nECHO|n ON, even though that's the default for any |nbatch file|n and it
doesn't normally have to be specified.  But |nECHO|n will still be off in the
                           <page down> for more
                              CALL continued
calling batch file, when you get back to it.

The called |nbatch file|n gets its own copy of the environment so it has the
same PATH, PROMPT, COMSPEC, and anything else that's in the original en-
vironment, but any variables changed during the called |nbatch file|n will
not be returned to the calling |nbatch file|n.  The calling |nbatch file|n keeps
the exact same |nenvironment|n that existed before the second |nbatch file|n was
called.

You can use replaceable parameters in a called |nbatch file|n also.  Just
enter the |nparameters|n on the |nCALL|n command line, like this:
          |nCALL|n BATCH2 ONE TWO THREE
This command would run the BATCH2.BAT file, with ONE as %1, TWO as %2,
and THREE as %3.

You can also call a |nbatch file|n that is not in the current directory, or
on the |nPATH|n, by specifying its full pathname like this:
          |nCALL|n C:\BELFRY\BATCH2
                           <page down> for more
                              CALL continued
If you use |nCALL|n (or |nCOMMAND|n /C) to run a second batch file from within a
first one, then as soon as the second |nbatch file|n is done, the first batch
file will continue right where it left off, at the line right after the
|nCALL|n (or |sCOMMAN|1D|s) command.

Of course you can still use the |nCOMMAND|n /C technique even if you have DOS
version 3.3 or later, but it's almost always more efficient to use |nCALL|n.

There is one situation in which it is useful to use this command at the
DOS prompt, rather than in batch files, and that has to do with the FOR
command.








                              The |TCLS|T Command

This is the easiest DOS command there is.  It CLears the Screen of any
data that might be on it, and puts the prompt and the cursor up in the
top left corner (called the "home" position).  No parameters, no syntax
to learn, just |nCLS|n.

It's used mostly in a batch file, to clear up any unnecessary messages
that may have been left on the screen.  It's also needed in many cases
if you're using the |nPROMPT|n command with ANSI.SYS ESC sequences to change
your screen colors.  Because a new ANSI color changing command does not
affect the whole screen, only whatever gets put on the screen after the
command is issued.  Also a lot of programs will reset your screen to some
other colors, so your chosen colors are gone when you exit from such an
application.  In many cases a simple |nCLS|n command will bring them back.

If |nANSI.SYS|n is installed, |nCLS|n works by sending ESC[2J to the screen.
This is the ANSI command that clears the screen.  If for any reason you
can't get the |nCLS|n command to work, try installing |nANSI.SYS|n with a DEVIC|1E
                           <page down> for more
                               CLS continued
command in your CONFIG.SYS file.

One interesting tidbit of information, about the fact that DOS sends the
ANSI.SYS ESC sequence 2J to the screen in order to execute this command,
is that it's an easy way to get the ESC character into a file, for use
in your own ANSI ESC sequences.  If you enter the command |nCLS|n > FILE.TXT
(see also |sRedirection|s) then instead of the screen clearing, a file will
be created that says ESC[2J only instead of ESC, it will actually contain
the ESC character, which looks like a little arrow.  Now you can edit the
file to replace the 2J with whatever ESC sequence you want.









                             The |TCOMP|T Command

This command is used to COMPare two files.  The syntax is really simple:
          |nCOMP|n D:\DIR\FILE1.EXT D:\DIR\FILE2.EXT
Where D: is the drive letter for each file, and |nDIR|n is the directory for
each file, and FILE#.EXT are the names and extensions of the files that
you want to compare to each other.

The command compares each byte of the first file, with each byte of the
second file, in order, and if there are ten mismatches, the command will
abort itself.  If there are less than ten differences, they will be dis-
played on the screen.  The format of the display is not very friendly,
however.  It will say something like "Compare error at offset 3 |nFile 1|n =
44 |nFile 2|n = 64".  That means that the fourth byte of the first file is a
capital D, and the fourth byte of the second file is a lowercase d.  Why
does it mean that?  Well the offset means how many bytes past the first
one, so offset 3 = byte 4.  And the 44 and 64 are the hexadecimal values
for the ASCII characters D and d.  If your version of DOS has the FC
command, you will usually want to use it instead of the |nCOMP|n command.
                           <page down> for more
                              COMP continued
It's much more friendly.  But if you're in a hurry, |nCOMP|n is much faster.

If the files have different byte sizes, the |nCOMP|n command won't even try
to compare them.

Some computer manufacturers that put out their own slightly different
versions of DOS include a |nCOMP|n command that's slightly different than the
way I've described it.  My description is for regular PC-DOS or MS-DOS
so yours could be a bit different, but it should have the same usage and
syntax.

One way in which this command is really useful despite its unfriendliness
is for copying really important files.  It is possible (although rare!)
for a computer to make a mistake, so you can just use the |nCOMP|n command on
the source and target files, after a COPY command, to be absolutely sure
that the copy was made perfectly.

You can use wildcards with this command, too.  If you want to compare
                           <page down> for more
                              COMP continued
every .BAT file on drive C: with each file of the same name on drive A:,
|nCOMP|n C:*.BAT A:\*.* will do it.  Since the second filename was specified
with *.* the command will just look for files with the same names.

MS-DOS version 5 brings good news to the |nCOMP|n command.  It has some swit-
ches that make it a lot friendlier.  The /D switch will display the dif-
ferences in decimal ASCII code instead of in hex numbers.  The /A switch
will actually show the characters instead of codes.  /L will show the
line number of the mismatch instead of the byte offset.  And the /N=#
switch will compare the first # lines of the files even if the byte size
of the files do not match.  Finally, the /C switch makes a non-case-sen-
sitive comparison.  In other words, D and d will not be regarded as a
mismatch.






                             The |TCOPY|T Command

This is the command you use to make a copy of one file and put that copy
somewhere else.  The original file stays right where it was before.  The
syntax is pretty straightforward:
          |nCOPY|n D:\DIR\FILE1.EXT D:\DIR\FILE2.EXT
where D: is the drive letter for the original source file and the drive
letter for the copy on the target drive.  |nDIR|n is the directory for the
original source file and the |ndirectory|n for the copy on the target drive.
And FILE#.EXT is the filename and extension for the original source file
and the filename and extension for the copy on the target drive.

Most of those parts of the command can usually be left out though.  If
the source file is in the current |ndirectory|n of the |ncurrent|n drive, then
the first D:\DIR\ part can be left out.  (COPY FILE1.EXT D:\DIR\FILE2
.EXT)  If the copy of the file that is to be placed on the target drive
is to have the same filename and extension as the source file, then the
FILE2.EXT part can be left out.  (COPY D:\DIR\FILE1.EXT D:\DIR)  If the
|ncurrent|n drive and |ndirectory|n are the target, and the filename and exten-
                           <page down> for more
                              COPY continued
sion are to remain the same as the source, then the entire target half
of the equation can be left out.  (COPY D:\DIR\FILE1.EXT)

Target files always start out with their Archive attributes set to on,
because they have just been created.  But even if the source file had a
Read-only attribute, the target file will not.  You'll have to use the
ATTRIB command to set the R attribute of the target file if you want to.

The |nCOPY|n command can also be used to combine two or more files into one.
This is called |tconcatenation|t, but it doesn't always work quite right in
all DOS versions.  Always take a look at the target file, and make sure
that it does contain each of the source files, before you even think
about deleting the source files!

Here are some examples of |nconcatenation|n:
          |nCOPY|n FILE1 + FILE2 BIGFILE
          |nCOPY|n FILE* BIGFILE
          |nCOPY|n FILE1 + FILE2
                           <page down> for more
                              COPY continued
That last one will use the first file specified, FILE1, as the target.
FILE2 will be appended to the end of FILE1.  FILE1 will no longer exist
in its original form, so be careful with that!

It's a good idea to make a quick |nbackup|n copy of each of the files you're
about to concatenate, before you start.  Like this:
          |nCOPY|n FILE* FILE*.BAK
          |nCOPY|n FILE1 + FILE2

If the files you're trying to concatenate end with <Ctrl-Z>, which is the
ASCII decimal 26, or End-of-File character, then the TYPE command will
show only the first source file when you |nTYPE|n the target file.  That's
because the |nTYPE|n command stops when it finds the first <Ctrl-Z> charac-
ter.  A lot of other sorts of programs do the same thing.  It will look
as if the concatenation didn't work at all.  What to do about that?  Well
you can use the /A switch with the copy command, on the source side of
the equation, as in |nCOPY|n FILE* /A BIGFILE.  This will cause the files to
be copied up to, but not including, their first <Ctrl-Z> characters.  (If
                           <page down> for more
                              COPY continued
there's more than one of these characters in a file, though, whatever
comes after the first one will be lost.)

The /A switch on the target side of the equation will cause a <Ctrl-Z> to
be added to the end of the target file.

The /A switch is the default for concatenation, but only when DOS real-
izes that |nconcatenation|n is what's going on.  Sometimes you can trick DOS,
you know.  So I just get into the habit of using the /A even when it is
the |ndefault|n, just to make sure DOS realizes that I'm trying to do some
|nconcatenation|n.  There are also times when you want DOS to use the /A
switch when you're not doing |nconcatenation|n at all.  Like if you have a
file that has a <Ctrl-Z> character at the end, and you want to remove
that character, |nCOPY|n /A FILENAME.EXT FILENAME.NEW /B will do it.

There is also a /B switch for the |nCOPY|n command, but it's not needed so
often because it is the |ndefault|n unless |nconcatenation|n is being done.  On
the source side, it tells |nCOPY|n to copy the whole file, according to the
                           <page down> for more
                              COPY continued
byte size listed in the file's directory entry, including, and past, any
<Ctrl-Z> characters that may be in the file.  On the target side, the /B
switch causes a <Ctrl-Z> character to not be added to the end of the tar-
get file.

An /A or /B switch applies to the file that precedes it, and also to any
files that follow it until the opposite switch is encountered.  So a com-
mand like |nCOPY|n FILE1 /B + FILE2 + FILE3 /A + FILE4 /B BIGFILE would cause
the /B switch to apply to all the files except FILE3.  And |nCOPY|n FILE1 +
FILE2 /B + FILE3 + FILE4 /A BIGFILE would have the /A switch applying to
FILE1, FILE4, and BIGFILE.

There is also a /V switch for the |nCOPY|n command, which tells DOS to VERIFY
the copy.  But this doesn't do very much good, and in fact if you use a
disk cache, it doesn't do a bit of good because DOS will end up verifying
the target file against the copy in the |ncache|n, rather than verifying the
target against the source file.  If you want to verify your copy, use the
FC or COMP command instead.
                           <page down> for more
                              COPY continued
Another use for the |nCOPY|n command is to send or receive data to or from a
device, instead of between two filenames.  For example, |nCOPY|n |nCON|n FILENAME
will take data from the keyboard (the input half of the CON device) and
send it to a file.  |nCOPY|n FILENAME /B |nCON|n will display a whole file, even
the parts past the first End-of-File character, to the screen (the output
half of the |nCON|n device).  This is about the only way you can display an
entire .COM or .EXE file on the screen with plain old DOS, because most
display methods stop at the first End-of-File marker.

Another device that's really useful with the |nCOPY|n command is PRN.  You
can print out a file with the command |nCOPY|n FILENAME |nPRN|n.  You can even
use |nCOPY|n |nCON|n |nPRN|n to make your printer act sort of like a typewriter.

When copying from |nCON|n to a filename or to |nPRN|n, as soon as you enter the
command, the cursor moves down one line and over to the left edge of the
screen, and sits there waiting for you to type something.  You type the
lines of text that you want to send to the file or to |nPRN|n, hitting the
<Enter> key after each line, and when you're all done, hit the <F6> key
                           <page down> for more
                              COPY continued
or the <Ctrl-Z> keystroke combination, hit <Enter> one more time, and
your "file" will be copied to the disk or to the printer.

Another use for |nCOPY|n |nCON|n is to add text to the end of a text file without
using a text editor.  |nCOPY|n |nCONFIG.SYS|n + |nCON|n will allow you to add lines
to the end of your CONFIG.SYS file.

If you want to "move" some files instead of just copying them it's really
sensible to always use the DIR command first, to make sure the files you
copied really made it to their destination, before you delete the source
files.  Suppose you give the command |nCOPY|n |n*.*|n A:\TEMP to copy all files
in the current directory to the TEMP |ndirectory|n in the root of the disk
in drive A:, and then |nDEL|n |n*.*|n to delete all the files in the |ncurrent|n dir-
ectory now that you have copied them to A:\TEMP.  But guess what?  You
had the wrong disk in the A: drive, and it didn't have a |ndirectory|n named
TEMP on it.  So now what you have is a huge file named TEMP on the disk
in drive A:, which is a concatenation of all those files that you thought
you just copied.  Well they're pretty useless now (unless they were all
                           <page down> for more
                              COPY continued
solid ASCII text) and your source files have already been deleted.  Too
bad.  If you had done a |nDIR|n A:\TEMP command before deleting the source
files, you would have seen that you had one huge file instead of the dir-
ectory that you thought you had, and you could have tried it again.  You
just can't copy files to a directory that doesn't already exist.

The |nCOPY|n command won't copy files that are 0 bytes long, but XCOPY will.

If you want to change the date and time in a file's |ndirectory|n entry to
the |ncurrent|n date and time on your system clock, without changing the
file, use the command |nCOPY|n FILENAME /B + ,, and the two commas will take
the place of the second source file and the target file, the file will be
copied to itself, the /B ensures that all of the file will be copied, and
since DOS thinks it's doing concatenation, it updates the date and time
of the file's |ndirectory|n entry.

If you copy a file to a |ndirectory|n where there is already a file by the
same name, the file you're copying will be copied right over top of the
                           <page down> for more
                              COPY continued
one that was already there, because DOS can only allow one file by a
certain name in each directory.  So before you copy a file, make sure
you're not going to overwrite a file that already exists by that name
in the target |ndirectory|n!  And this especially applies to the use of
the |nCOPY|n |nCON|n command!  So many people will advise you to use that com-
mand to write an AUTOEXEC.BAT or CONFIG.SYS file, but they forget to
warn you that if you already have a file by that name, this command'll
erase the old copy completely!

See the section on the RENAME command for some information about how
the meaning of wildcards differs slightly between the source side and
the target side of a command, when you're copying files to different
names than what they had before.






                              The |TFOR|T Command

This is mainly a batch file command, but it is also very useful at the
DOS prompt.  It works sort of like replaceable parameters.  Example:
          |nFOR|n %%a IN (*.BAT) DO |nTYPE|n %%a
What that command will do, is to expand the wildcard specification *.BAT
into all the filenames that fit it, and then type each one to the screen.
This is useful because the TYPE command does not work on wildcards.

How about the DEL command?  It doesn't work on more than one filename at
a time unless the filenames can be named by a wildcard specification.  So
you could do this:
          |nFOR|n %%a IN (FILE1.TXT TEXT2.FIL LETTER3.DOC) DO |nDEL|n %%a
This command will replace the %%a in the |nDEL|n command, with each filename
listed in parentheses, in turn, and delete each one.

You can also use the %%a variable to fill in for the commands to be exec-
uted, instead of for the |nparameters|n to the command.  Like this:
          |nFOR|n %%a IN (|nTYPE|n |nPAUSE|n |nDEL|n) DO %%a FILE1.TXT
                           <page down> for more
                               FOR continued
This command will type the FILE1.TXT file to the screen, then pause for
a keystroke, and then delete the file.  If, by seeing the file on the
screen, you realize that you didn't really want to delete it, you could
hit <Ctrl-C> instead of any other keystroke, when PAUSE is waiting for
input, to BREAK out of the batch file without deleting FILE1.TXT.  If
you hit anything else besides <Ctrl-C> or <Ctrl-Break>, then FILE1.TXT
will be deleted.

Now what would make that particular command really useful, is if you used
a replaceable parameter instead of a particular filename.  Like this:
          |nFOR|n %%a IN (|nTYPE|n |nPAUSE|n |nDEL|n) DO %%a %1
Now if that command were in a |nbatch file|n named D.BAT and you used it with
a command line like D FILE1.TXT, then FILE1.TXT would be placed where the
|nbatch file|n says %1, or if the next time you executed that |nbatch file|n, you
said D LETTER.DOC, then that time LETTER.DOC would be the file that the
TYPE, |nPAUSE|n, and DEL commands would act on.

You're probably wondering why it's not just as good to use a |nbatch file|n
                           <page down> for more
                               FOR continued
like this instead of that one complicated command:
          |nTYPE|n %1
          |nPAUSE|n
          |nDEL|n %1
Well that batch file will do the exact same thing, just less efficiently.
Remember that DOS executes batch files by reading the first line off the
disk, then executing it, then reading the next line off the disk, then
executing it, then reading the next line off the disk, etc.  In other
words, it's slow.  If you put all three of those commands on one line by
using the |nFOR|n command, then you have a more efficient |nbatch file|n.  I
know, it's only a difference of a couple milliseconds if you're using a
decent hard drive.  But what if you have a one-floppy-drive system?  And
what if the |nbatch file|n is on one disk and the file you want to delete is
on another?  Then you put the |nbatch file|n disk into the drive and execute
it like D B:LETTER.DOC (remember that on one-floppy-systems, DOS acts
like you have an A: drive and a B: drive, and asks you to switch disks
when necessary) so the first line of the |nbatch file|n is read from the disk
and then you are requested to put the drive B: disk into the drive, and
                           <page down> for more
                               FOR continued
the file is typed to the screen.  Then DOS needs you to put the batch
file disk back into the drive so it can read the second line of the batch
file.  Then when the third line of the batch file comes, you have to
change disks again so that DOS can delete the file.  Then you have to put
the |nbatch file|n disk in one more time so that DOS can look to see if there
were any more commands in the |nbatch file|n or not.  Well if the |nFOR|n command
had been used instead, then DOS would only need the |nbatch file|n disk twice
instead of three times.  (Yeah, I know, big deal, right?)

Another way to use replaceable parameters with the |nFOR|n command is to put
them into the parentheses, like this:
          |nFOR|n %%a IN (%1 %2 %3 %4 %5 %6 %7 %8 %9) DO |nTYPE|n %%a > |nPRN|n
Now you can specify anywhere from one to nine filenames on the command
line, and they will be typed to the printer, all with just one command.

Here's a strange one.  Suppose you need a way to make a |nbatch file|n pause
for a couple moments, without requiring any keyboard input to make it
start going again.  How about this:
                           <page down> for more
                               FOR continued
          |nFOR|n %%a IN (1 2 3 4 5 6 7 8 9 0) DO |nCHKDSK|n
Since there's no %%a in the ending part of that command, the numbers in-
side the parentheses have no effect on the CHKDSK command, but they just
cause the |nCHKDSK|n command to be performed ten times over.  This would put
a decent-length pause into your batch file.  It's not a real good idea to
do it though, because that's a good bit of wear-n-tear on your hard drive
for no good reason.  But it was just an example of how you can use |nFOR|n to
execute the same command some specified number of times.

Personally, I find the most use for the |nFOR|n command at the DOS prompt
rather than inside batch files, even though all the books usually say
that |nFOR|n is just a |nbatch file|n command.  How about if you want to copy
eight files that can't be covered in one wildcard specification, from
one disk to another?  Without the |nFOR|n command you have to give the first
COPY command, wait for that to finish, give another |nCOPY|n command, wait
for that one, give another command, wait, etc.  Using |nFOR|n instead:
          |nFOR|n %a IN (FILE1.TXT TEXT2.FIL LETTER3.DOC ABCDE.DOC FOOBAR.DOC
                           TEXT6.DOC LETTER7.FIL FILE8.TXT) DO |nCOPY|n %a B:
                           <page down> for more
                               FOR continued
Now as long as that all fits on a 127-character command line, all the
copying will be done while you sit back and watch.

Notice that time I said %a instead of %%a.  At the DOS prompt you only
want one percent sign (%), while inside a batch file, you need two.

You don't have to use %%a or %a.  You could use %B or %q or %Z or what-
ever you want.  Any letter, |nupper|n or lowercase will do, as long as it's
a letter, and it's the same at the beginning and the end of the same com-
mand.  For example, |nFOR|n %%a IN (*.*) DO |nDEL|n %%A won't work because DOS
will be looking for some %%A file to delete, when all it has is some %%a
files.  DOS does not think of |nupper|n and lowercase letters as the same.

That was a good command, though, if it had the same variable at the be-
ginning and the end.  |nFOR|n %%a IN (*.*) DO |nDEL|n %%a will do the same thing
as |nDEL|n |n*.*|n but it won't ask you "Are you sure? (y/n)" because as far as
the DEL command knows, you're only deleting one file at a time instead of
a whole directory.
                           <page down> for more
                               FOR continued
In many ways, the |nFOR|n command acts like a miniature batch file, even when
you're using it from the DOS prompt.  For example, if you want to use the
|nFOR|n command to execute a |nbatch file|n, you have to use the CALL or COMMAN|1D
command, even if you're working at the command line instead of within an-
other |nbatch file|n.  Without |nCALL|n or COMMAND, the |nbatch file|n will be exec-
uted with the first parameter in the set in parentheses, and then you'll
get your DOS |nprompt|n back.  DOS will think it's done with what you told it
to do because the |nbatch file|n it was working on has finished.  The |nCALL|n or
COMMAND /C command will cause the |nbatch file|n, when it's done, to return
control to the |nFOR|n command instead of to the DOS |nprompt|n.  Here's an exam-
ple, supposing you have a |nbatch file|n named BATCH.BAT:
          |nFOR|n %a IN (*.*) DO |nCALL|n BATCH %a
And of course BATCH.BAT must have a %1 replaceable parameter inside it,
or else there's no point in trying to feed it a %a parameter.  So, the
|nCALL|n command is not completely useless at the DOS |nprompt|n after all, the
way most people think it is!



                                 The |tPATH|t

A |npath|n in DOS is just the road that DOS would have to follow through the
directories, in order to find a file that you want it to find.  For a
file named FOO.BAR in the subdirectory called ABC which is a subdirec-
tory of the subdirectory called DEF which is a directory on the D: drive,
(got that?) the full filespec for that file would be D:\DEF\ABC\FOO.BAR,
and the \DEF\ABC\ part is the |npath|n for that file.

When you type in a command at the DOS prompt, if you have not specified
the |npath|n to the command file on the command line, and if the command is
not an internal part of COMMAND.COM, then DOS will search the current
|ndirectory|n for the file, and if it's not there, DOS will search each dir-
ectory listed on the |nPATH|n variable in the environment.  When you first
boot up your computer, the |nPATH|n variable looks like this:
          |nPATH|n=
It's not set equal to anything!  (You can use the |nSET|n command to view the
strings that are in the |nenvironment|n.)  Therefore, any external command
that's not in the |ncurrent|n |ndirectory|n (unless you've specified the correct
                           <page down> for more
                              PATH continued
|npath|n on the command line), will not be found, and you will receive the
famous "|tBad command or filename|t" message.  What you need to do is put a
|nPATH|n statement into your AUTOEXEC.BAT, which lists all the directories
where your most common commands reside.  That way, DOS will know where
to look to find these command files in order to execute them, even if
you are not |scurrent|sly in the directory where they reside.

All of your DOS commands that came with your computer should be in a dir-
ectory called DOS.  This should be one of the first directories listed on
your |nPATH|n.  DOS searches the directories in the order in which they are
listed on the |nPATH|n statement.  So you don't want the |ndirectory|n which con-
tains your most commonly used commands at the end of the |nPATH|n statement,
because this will increase the time it takes for DOS to find the command
file.

Why don't you just put all of your directories on the |nPATH|n?  Three rea-
sons:  First, the entire |nPATH|n statement, including |nPATH|n=, can only be 127
characters long!  Second, most programs don't know how to find their com-
                           <page down> for more
                              PATH continued
panion files using the |nPATH|n statement, and those programs that don't know
how to use an environment variable either, to find their companion files,
won't be able to find their companion files unless the files are in the
current directory.  Therefore, there would be no purpose in having this
|ndirectory|n on the |nPATH|n, since if you start the program from another direc-
tory, the program won't be able to run anyway.  For this type of program,
you have to change to the program's |ndirectory|n before you run it, and that
is all there is to it!  Third, the longer the |nPATH|n statement, the longer
it will take DOS to search all the directories on it, in order to find a
command file that you've asked it to execute!  A batch file is a very
simple and effective way to avoid having a long |nPATH|n variable.

Here's an example of a |nPATH|n statement:
          |nPATH|n C:\DOS;C:\UTIL;C:\DOS\BIN
Notice that each |ndirectory|n specified is separated from the others with a
semicolon (;).  And always include the full |ndirectory|n specification for
each |ndirectory|n, including the drive letter, as above, instead of some-
thing like |nPATH|n \DOS;\UTIL;\DOS\BIN, because if the drive letter is not
                           <page down> for more
                              PATH continued
included, then when you have A: as your current drive, your |nPATH|n won't
work at all, because DOS will be searching on A: for the \DOS, \UTIL, and
\DOS\BIN directories, which don't exist on drive A:.  They're on C:.

Notice that in most cases, you need to use the SET command to set an
environment variable, but for |nPATH|n and PROMPT, the set command is not
required.  Also, on some systems, an equals (=) sign is required between
|nPATH|n and the rest of the statement.  So if something like |nPATH|n C:\DOS;
C:\ABC won't work on your system, use |nPATH|n=C:\DOS;C:\ABC instead.  There
must never be any spaces in the |nPATH|n statement, except between |nPATH|n and
the rest of it, and there should not be a semicolon (;) after the last
directory name!

Remember, though, that a |nPATH|n statement is never a requirement.  It is
only a time-saver for you.  DOS could just as easily find any command
file if you were to include the full file specification for the command,
on the command line.  For example, if you have a file named EXPLOSIV.COM
in the \UTIL |ndirectory|n of the C: drive, and C:\UTIL is not on your |nPATH|n,
you can enter the command as C:\UTIL\EXPLOSIV rather than just EXPLOSIV.
                             The |TSHIFT|T Command

This is a batch file command which has no use whatsoever at the DOS
prompt.  Its only purpose is in conjunction with replaceable parameters.
All it does is shift everything over to the left.  Huh?

Well, suppose you are using a whole bunch of |nreplaceable|n |nparameters|n in a
|nbatch file|n.  All that's strictly allowed is %0 to represent the name of
the |nbatch file|n, and then %1 through %9 for whatever you want to use them
for.  What if you need more than nine?  That's what |nSHIFT|n is for.  Here's
the command line we'll use for an example:
          D 1.TXT 2.TXT 3.TXT 4.TXT 5.TXT 6.TXT 7.TXT 8.TXT 9.TXT 0.TXT
Well, the name of the |nbatch file|n, D, is %0.  The first parameter, 1.TXT,
is %1, the second one, 2.TXT, is %2, etc., up until the tenth one, 0.TXT,
which doesn't have any %# because there's no such thing as %10.  So, how
are we going to use it?  Well, as soon as we are done, in the |nbatch file|n,
with whatever we needed to do to %1 through %9, we could use the |nSHIFT|n
command which will move everything over one space to the left.  The name
of the |nbatch file|n will no longer have any %#, 1.TXT will become %0, and
                           <page down> for more
                              SHIFT continued
2.TXT is now %1, etc., up until 0.TXT becomes %9.  Now 0.TXT can have a
%# even though it's the eleventh word on the command line.  If there were
another file, say 11.TXT, on the command line, then another |nSHIFT|n command
would make 1.TXT not have any %#, and 2.TXT would be %0, 3.TXT gets %1,
etc., until 0.TXT is %8 and 11.TXT is %9.  So it is conceivable to have
an unlimited number of parameters on the command line (as long as the to-
tal length of the command line is 127 characters or less).  You just need
to have as many |nSHIFT|n commands in the batch file as there are |nparameters|n
past the ninth one.

The |nSHIFT|n command also comes in handy when you want to do the exact same
thing to a whole bunch of |nparameters|n, and you could be using a different
number of |nparameters|n each time.  Let's use that same sample command line
above, and say that D.BAT looks like this:
          :START
          |nDEL|n %1
          |nSHIFT|n
          IF !%1==! |nGOTO|n END
                           <page down> for more
                              SHIFT continued
          |nGOTO|n START
          :END
Well, the first line is just a label for the GOTO command.  Since it
starts with a colon (:), it will be completely ignored until such time as
DOS sees the |nGOTO|n command, so having it as the first line is not a prob-
lem.  The next line just deletes the file that currently has the value of
%1.  Right now, since there has not been any |nSHIFT|n command yet, it is the
first word after the name of the batch file on the command line.  The
next line shifts everything on the command line, one space to the left,
so that now what was %1 is now %0, what was %2 is now %1, etc.  The next
line checks to see if we're done yet.  If, after the shift, there is no-
thing left to put into %1, then DOS will expand this line to say IF !==!
|nGOTO|n END (because %1 is now "nothing") and since ! does equal !, the
|nbatch file|n will |nGOTO|n END.  But if there is still something left on the
command line after the shift, so that %1 does not equal nothing, then the
line will be |nexpanded|n to say, for example, IF !2.TXT==! |nGOTO|n END, and
since !2.TXT does not equal !, the |nGOTO|n END command will be ignored, and
the |nGOTO|n START command will be executed instead.  This just keeps on go-
                           <page down> for more
                              SHIFT continued
ing until however many files were included on the command line, have
been deleted, at which time %1 will be equal to nothing, and the batch
file will end.  So you see, you can use this |nbatch file|n to delete one
file, three files, or twenty files (if you can fit all their names on
a 127-character command line), with just one command.














                            Code Page Switching

|TCHCP|T, |TCOUNTRY|T, |TGRAFTABL|T, |TKEYB|T, KEYB??, |TNLSFUNC|T, DISPLAY.SYS, PRINTER.SYS,
and SELECT are all commands and |sdevice driver|ss that have no use other
than to enable code page switching.  Ignore them.  The files in your DOS
directory which have the extension .CPI are the tables that these com-
mands use.  Ignore them too.  The MODE command is also used for code page
switching, but at least it has useful functions as well.

Oh, ok, I'll at least tell you what code page switching actually is.  IBM
could have picked a much simpler name for this stuff.  All it means is,
setting DOS up to be able to use characters like Ä and ö for foreign lan-
guage alphabets, instead of the alphabet that we use here in the good old
U. S. of A.  The code page used for plain old English is the default, so
you don't have to set up anything special to use it.  But if you want to
type in a different language, then you need to set up its code page, so
you can use those foreign-language characters.  So that's what code page
switching is all about.


                           Reserved DOS |tDevice|1s|t

A device driver is a piece of software that tells DOS how to deal with
some external peripheral device that connects to the computer.  Well DOS
already knows how to deal with a few peripheral devices, because it has
some built-in device drivers for those devices.

These devices that DOS automatically knows how to work with have their
very own special names, and you mustn't try to use those names for any-
thing else, such as filenames or anything.  For example, if you tried to
use the command |nCOPY|n FILE.TXT |nNUL|n.TXT to make a copy of FILE.TXT and call
it |nNUL|n.TXT, DOS would completely ignore the .TXT extension and use the
device |nNUL|n instead of the filename you thought you were using.  DOS would
copy the FILE.TXT file to the |nNUL|n device, which means "nowhere" and you
would not end up having the intended copy of that file at all.

Why does the |TNUL|T device mean "nowhere"?  Well, it just does.  It is a
name for a device that doesn't really exist.  What good is it?  Plenty.
For one thing, if you want to check the integrity of a file that's sit-
                           <page down> for more
                             Device|1s continued
ting on a disk that you think you might have damaged, you can copy the
file to the NUL device and if DOS gives an error message, then you know
the file has been damaged.  If there's no error message then the copy was
successful, which means the file was readable.  Of course you could al-
ways just copy the file to another disk or directory, but unless you wan-
ted an extra copy of it anyway, then you'll just have to delete the file
after the test.  Using |nNUL|n as the COPY command's destination saves that
step.

The most common use for the |nNUL|n device is to make the execution of a
batch file cleaner.  Suppose you have |nCOPY|n commands in your AUTOEXEC.BAT
file that copy files to your RAMdisk.  Well after each of those files are
copied, DOS shows the message "1 File(s) copied" on the screen.  You
don't want to look at that every time you boot your computer, do you?
Well you could put > |nNUL|n at the end of each |nCOPY|n command, and since the
"1 File(s) copied" message is sent to STanDard OUTput, the > symbol will
use redirection to send that message to the |nNUL|n device and you won't have
to look at it on the screen anymore.
                           <page down> for more
                             Device|1s continued
The |TPRN|T device is just another name for |nLPT1|n.

|TAUX|T is another name for |nCOM1|n.

|TLPT1|T is the first parallel port, or printer port.  If you have a printer
hooked up to it, you can print out a file by typing |nCOPY|n FILE.EXT |nLPT1|n or
|nCOPY|n FILE.EXT |nPRN|n.  If your printer is hooked up to a serial port in-
stead, you can use the MODE command, as in |nMODE|n |nLPT1|n = |nCOM1|n to redirect
everything that DOS sends to |nLPT1|n, to |nCOM1|n instead.  Then you'll be able
to use the |nPRN|n device as if your printer was on |nLPT1|n.

|TCOM1|T is the first serial port, or communications port.  Modems, printers,
and mice are three things that are very commonly connected to serial
ports.  If your modem has gone offhook and you can't get it to hang up,
you can use the command |nECHO|n ATH0 > |nCOM1|n if your modem is on |nCOM1|n, to
make it hang up.  (If your modem is Hayes-compatible, that is.)

What's the difference between a parallel port and a serial port?  Oh, a
                           <page down> for more
                             Device|1s continued
big difference!  A serial port sends bits (eighths of a byte) of data in
a serial fashion, that is, one after another.  Just one bit at a time.  A
parallel port sends data through eight parallel wires, so that eight bits
(one byte) go through the port at a time.  So it's pretty safe to assume
that a parallel port will send a certain amount of information eight
times as fast as a serial port will.  But printers are just about the on-
ly things that are very commonly hooked up to parallel ports.  Modems and
mice just can't use parallel ports, even though it would be nice if they
could because of the speed difference.

The |TCLOCK$|T device can't really be used for any purpose from the command
line or anything.  It refers to the clock that DOS uses to keep track of
elapsed time.  (This is not the same as any battery-backed clock you
might have installed on your system.)  Whatever time this clock says is
the time that will be listed in a file's directory entry every time you
update it.  The only reason you need to know the name of this device is
just so you never try to use that name for a filename, since it is a re-
served DOS device name.
                           <page down> for more
                             Device|1s continued
Ok, I saved the best device for last.  |TCON|T is the device that DOS uses
for STanDard INput (STDIN), STanDard OUTput (STDOUT), and STanDard ERRor
(STDERR).  Unless there has been some redirection performed, then STDIN
is the keyboard and STDOUT is the monitor screen.  STDERR is always the
monitor.  There are a whole lot of things you can do with the |nCON|n device
name, such as |nCOPY|n |nCON|n |nPRN|n to make your printer act sort of like a type-
writer, or |nCOPY|n |nCON|n FILENAME to create an ASCII file without using a text
editor or anything.  See the section on the COPY command for details.

A lot of books show the device names as |nCON|n: or |nPRN|n: or |nLPT1|n:, with the
colons after them, but they work just fine with or without the colons.
I think the colons are mostly used just to differentiate between device
names and filenames, so that you don't think they're referring to some
filename when they say |nCON|n:.





                             The |TCTTY|T Command

I have no idea what that stands for, but I know what it does.  It trans-
fers control of your system to some other device.  Like if you have a
second monitor and keyboard connected to your COM1 port (also known as
|sAUX|s), then you could give the command |nCTTY|n |nAUX|n and output would go to the
second monitor, and input would be accepted from the second |nkeyboard|n.
Then when you're ready to go back to the main monitor and |nkeyboard|n, then
on the second |nkeyboard|n you type |nCTTY|n |nCON|n and that puts things back to
normal.

Well the only use I've ever found for |nCTTY|n, since I don't have any other
monitors or keyboards hooked up, is for cleaning up the screen display
during execution of a batch file.  If you have a whole bunch of COPY
commands in a row in a |nbatch file|n, you get a screen that looks like this
when you execute that |nbatch file|n:
          1 File(s) copied
          1 File(s) copied
          1 File(s) copied
                           <page down> for more
                              CTTY continued
Now who wants to look at a screen like that?  Not I.  If you're very
careful and make sure you don't forget the |nCTTY|n |nCON|n command at the end,
you can put |nCTTY|n |nNUL|n at the beginning of the list of COPY commands in the
batch file, like this:
          |nCTTY|n |nNUL|n
          |nCOPY|n FILE1.TXT D:
          |nCOPY|n FILE2.TXT D:
          (Etc.)
          |nCTTY|n |nCON|n
If you forget the |nCTTY|n |nCON|n at the end there, you'll be in big trouble.
Because your computer is no longer accepting any input from the keyboard.
You can't enter the |nCTTY|n |nCON|n command from the |nkeyboard|n, because DOS is
only accepting input from the NUL device, which doesn't even exist.  So
don't forget the |nCTTY|n |nCON|n command.

Another possible problem with |nCTTY|n |nNUL|n, is that it redirects not only
STanDard INput and STanDard OUTput, but also STanDard ERRor.  So even the
error messages that would normally show on screen will go to the |nNUL|n de-
                           <page down> for more
                              CTTY continued
vice instead.  You won't know if there have been any errors.  So don't
use |nCTTY|n |nNUL|n unless you're sure that the procedure that comes after that
command will never cause any errors.  For example if you're copying files
to a RAMdisk whose letter is D:, you could use a command like IF NOT EX-
IST D:\NUL |nGOTO|n END to make sure that the |nRAMdisk|n was properly created,
before you use |nCTTY|n |nNUL|n and start copying.  (See the section on EXIST for
details on that command.)  And make sure that there's no possible way
that the batch file can possibly skip the |nCTTY|n |nCON|n command, such as be-
cause of a GOTO command or a syntax error.

Now if you ever need to use CON while you're in the middle of a |nCTTY|n |nNUL|n
section of a |nbatch file|n, you don't have to do |nCTTY|n |nCON|n then do your stuff
then do |nCTTY|n |nNUL|n again.  For example, if you need to use a PAUSE command,
you can do it like this:
          |nECHO|n Don't even THINK about using Ctrl-C or Ctrl-Break > |nCON|n
          |nECHO|n Strike any key to continue. . . .  > |nCON|n
          |nPAUSE|n < |nCON|n
This method uses redirection to send a message to the screen even though
                           <page down> for more
                              CTTY continued
output has been redirected to NUL, and the third line will accept a key-
stroke from the keyboard even though input has been redirected to |nNUL|n.
Now if a body were to type the <Ctrl-C> or <Ctrl-Break> combination while
PAUSE is waiting for a keystroke, that would break out of the batch file
so that the |nCTTY|n |nCON|n command would not get executed.  There's not a thing
you can do when that happens except reboot.  Because the |nNUL|n device is
never going to send the command |nCTTY|n |nCON|n to DOS, and that's the only
place DOS is accepting input from while a |nCTTY|n |nNUL|n command is in effect.

One more problem with this command, is that it only works on STDIN, STD-
OUT, and STDERR.  That means STanDard INput, STanDard OUTput, and StanD-
ard ERRor.  Those are the normal methods that DOS uses to communicate
with the CON device|1s (monitor and keyboard).  Well there are many pro-
grams that read directly from the |nkeyboard|n and/or write directly to the
video memory, and those programs will continue to use your normal |nCON|n de-
vice rather than |nNUL|n or AUX or whatever you had redirected it to using
the |nCTTY|n command.  Because these programs are rude and bypass DOS to talk
directly to the |nkeyboard|n and video adapter.

                        The |TDATE|T and |TTIME|T Commands

These commands are pretty straightforward.  If you enter the |nDATE|n command
with no parameters, its output will look about like this:
          |nCurrent|n date is Wed 06-19-1991
          Enter new date (mm-dd-yy): _
And it sits there waiting for you to either tell it the correct date, or
hit the <Enter> key to accept the date that is already there.  You can
also enter the command with a date, as in |nDATE|n 06-19-91, and that will
just set the date and immediately give you a new prompt.

If you enter the |nTIME|n command with no |nparameters|n, here's the display:
          |nCurrent|n time is 5:32:34.54p
          Enter new time: _
You can also enter the new time right on the command line, as in |nTIME|n
5:32p or |nTIME|n 17:32.  In most DOS versions, you can use a period instead
of a colon to divide hours from minutes.  That's easier than messing with
the <Shift> key to type a colon.  If you have DOS version 3.3 or earlier,
you're on a 24-hour clock like the military uses, instead of being able
                           <page down> for more
                          DATE and TIME continued
to use a or p for a.m. or p.m.  So if it is after noon, you add 12 hours
to the time.  For example, 6 p.m. is 18:00 on a 24-hour clock.

If your computer doesn't have an internal battery-backed clock, then you
need to have the |nDATE|n and |nTIME|n commands in your AUTOEXEC.BAT file so that
you'll have a chance to set the date and time in DOS's system clock each
time you reboot.  Otherwise your system clock will be reset to 01-01-80
and 12:00 or something like that.  Now whatever values are in DOS's sys-
tem clock (the name of which is |sCLOCK$|s) are the values that will be put
into the directory entries of every file that you update, and if the dir-
ectory entries get the wrong values, then an incremental backup will act
on the wrong files.  That's just one of the very important reasons for
keeping the right date and time in the system clock.  So without a bat-
tery-backed clock, regardless of what a pain in the neck it is, you real-
ly do need to have these two commands in your |nAUTOEXEC.BAT|n file.

If you boot from a disk that doesn't have an |nAUTOEXEC.BAT|n file on it, or
if that file is not in the root |ndirectory|n where DOS knows how to find it,
                           <page down> for more
                          DATE and TIME continued
then DOS will automatically execute the |nDATE|n and |nTIME|n commands when it's
done booting up.  If you do have an AUTOEXEC.BAT file, then DOS will only
execute these two commands if they are included in that file.

If you have DOS version 3.3 or later, and a hardware clock whose memory
address is the same as that used on true IBM brand computers, setting the
date or the time will automatically update the battery-backed hardware
clock so that the values will still be correct the next time you boot the
computer.  If you have an earlier DOS version, then you have a command
file somewhere, that came with your computer, that allows you to change
the date and time that's stored in the hardware clock, because DOS won't
do it for you.  Also it could be just a part of your CMOS setup, if you
don't have any command file for that purpose.  Of course, ignore this
paragraph if you don't have a hardware clock.

If you want to display the date or time without DOS stopping to wait for
you to press <Enter> or enter a new value, it can be done.
          |nECHO|n || |nMORE|n || |nDATE|n
                           <page down> for more
                          DATE and TIME continued
will usually do it.  That's because the ECHO command always sends a car-
riage return (the <Enter> key) along with whatever else it's sending.

Well in this case it sends the words "|nECHO|n is on" and a carriage return
to the MORE command, and the |nMORE|n command somehow strips out the words
"|nECHO|n is on" and just sends the carriage return along to the |nDATE|n com-
mand, which makes the |nDATE|n command act as if you had hit the <Enter> key
from the keyboard, after it had stopped and waited for your input.  (See
the redirection section for information on the || symbol.)

A similar method can be used to enter the |ncurrent|n date or time into an
environment variable for use in a batch file.  You'll need to write two
batch files to make this work.  You might call the first one TIMEVAR.BAT:
          |nECHO|n HELLO || |nMORE|n || |nTIME|n > HELLO.BAT
          HELLO
And the second |nbatch file|n has to be named |nCURRENT|n.BAT:
          |nSET|n |nTIME|n=%3
Now what happens is that the first command in TIMEVAR.BAT uses the same
                           <page down> for more
                          DATE and TIME continued
method as above to display the |ncurrent|n time on the screen without wait-
ing for any input.  Only this time, instead of the display going to the
screen, a file named HELLO.BAT is created which contains the output of
the |nTIME|n command.  The next line of TIMEVAR.BAT runs HELLO.BAT:
          |nCurrent|n time is 5:32:34:54p
Which runs |nCURRENT|n.BAT with "time" as %1 and "is" as %2 and "5:32:34.54p"
as %3.  So the command inside |nCURRENT|n.BAT sets an environment variable
named |nTIME|n, equal to the |ncurrent|n time at the time this series of batch
files was executed.  (See also redirection and replaceable parameters.)

If you want to have the |ncurrent|n time displayed as part of your prompt,
can use the $t |nprompt|n metacharacter to do that, but it will show you a
time like 17:15:43.72 and you don't want to see that, right?  But there
is also a $h metacharacter that is the <Backspace>.  So if you used the
command |nPROMPT|n $t$h$h$h$h$h$h$g, that would give you the time, and six
backspaces, and the > symbol, so it would look like 17:15> instead of
that ugly one that included the seconds and hundredths of seconds.  And
you can also use the $d |nprompt|n metacharacter, to give you the date.

                             The |TDEBUG|T Command

The only thing I really have to say to a beginner about this command, is
leave it alone.  If you don't know how to use it, then you don't know
enough about computers to have any business messing with it.  I don't
mean to sound harsh or anything but this is a highly powerful (meaning
dangerous, in the wrong hands) command.  One slip of a finger and you
could easily trash every speck of data on your entire hard disk.  You
can even damage the hardware itself with this command, believe it or
not!  Don't use it unless you know what you're doing!

That doesn't mean you should necessarily delete it from your hard disk,
however.  There are some things you can safely use it for.  PC Magazine
and several other computer-related magazines publish little scripts that
you can type in and then use |nDEBUG|n to assemble them into .COM files.
This gives you a way to get some little utilities such as CAPSLOCK.COM
without buying or downloading anything.  You can sit right in your living
room and create utilities that can perform all sorts of functions.  If it
weren't for |nDEBUG|n, you couldn't do that.  And it's really quite safe as
                           <page down> for more
                              DEBUG continued
long as you proofread each line you type in, before you hit the <Enter>
key, and just carefully follow the instructions in the magazine.

If you ever accidentally execute this command, you will get a prompt that
just looks like this:
          -
That's it.  That's the |nDEBUG|n |nprompt|n.  Just type a Q and hit the <Enter>
key, and you'll be right back in DOS.

Anyway, the main purpose of this command is to examine and modify data
either in memory, or on disk.  It's called |nDEBUG|n because its main purpose
is supposed to be for debugging programs that a programmer is in the pro-
cess of writing.  But hardly anybody ever uses it for that.  In fact,
hardly even any programmers use it for that.





                        The |TDEL|T and |TERASE|T Commands

These commands are interchangeable.  They are used to permanently remove
any file from any disk.  Ok, there are utilities such as PC Tools that
can undelete a file, and in DOS version 5.0 there is even an UNDELETE
command.  So deletion or erasure isn't always permanent.  If you realize
right away that you made a mistake, you can use one of those utilities,
or if you have DOS 5.0 you can use the |nUNDELETE|n command.  But if you do
not realize that you deleted the wrong file, until you or some program
has written some information to the disk, then maybe that information got
written right on top of where that deleted file was, and there's no way
to get that file back then!  So you should always act like |nDEL|n and |nERASE|n
are permanent even though that's not exactly true.

The syntax is really easy.  |nDEL|n FILENAME.EXT or |nERASE|n FILENAME.EXT is all
there is to it.  DOS version 4.0 or later adds a /P switch, which causes
DOS to stop and ask if you're sure.  This is useful when you're deleting
a group of files by using wildcards, because DOS will name each file that
it's about to delete, and if there was one that you didn't want to delete
                           <page down> for more
                          DEL and ERASE continued
you can say no.

If you have DOS version 4.0 or later you should always use the /P switch
if you're using wildcards.  For earlier versions, you should first use
the DIR command with the wildcard specification you're planning to use,
and it will show you the files that fit that wildcard spec.  If those are
indeed the files that you want to delete, then just type |nDEL|n and hit the
<F3> key which will copy the wildcard specification that you'd used from
the template (DOS's |nmemory|n of the last command you entered) onto the cur-
rent command line and you can execute the command without a chance of de-
leting the wrong files.  (See also editing keys.)

You can also use this command to delete all the files in a directory.
For recent versions of DOS, you just use the |ndirectory|n name in place of
the filename.  For earlier versions, you use the *.* wildcard specifica-
tion.  If your current |ndirectory|n is C:\ and you want to delete all the
files in C:\WP\LTRS you can just enter the command |nERASE|n WP\LTRS or |nERASE|n
WP\LTRS\*.* and DOS will say "Are you sure?" and you say "Y" and all
                           <page down> for more
                          DEL and ERASE continued
those files are gone.  DOS always asks if you're sure if you try to del-
ete a whole directory worth of files all at once.  If you want to remove
the |ndirectory|n after you have removed all the files from it, use the RMDIR
command.

There are a couple of ways to get around that question, though.  Don't
ever use this method without specifying the complete |spath|sname of the
files in question, because you might accidentally erase all the wrong
files, but here it is:
          |nECHO|n Y || |nDEL|n C:\WP\LTRS\*.*
The ECHO command sends the Y and a carriage return (the <Enter> key) to
the |nDEL|n command by means of redirection using the || symbol, so when DOS
asks you "Are you sure?" it finds that the "Y" is already waiting for it.

Another way is |nFOR|n %%a IN (C:\WP\LTRS\*.*) DO |nDEL|n %%a.  That method will
work without even asking the question, because DOS won't realize that
you've asked it to delete the whole |ndirectory|n at once.  It thinks it's
deleting one file at a time.  (See the section about the FOR command.)
                           <page down> for more
                          DEL and ERASE continued
Just don't ever forget that if DOS asks you "Are you sure?" after you en-
ter a |nDEL|n or |nERASE|n command, that it's trying to tell you that it's about
to delete every file from some directory or another.  If that's not what
you had in mind, then say no and take another look at the command you had
entered.

The |nDEL|n and |nERASE|n commands don't actually do a thing to the data in the
files that they delete.  All they do is to zero out the first bytes of
the |ndirectory|n and FAT entries for the files, so that DOS doesn't know
they're there anymore.  The files are still on the disk, it's just that
DOS can't find them.  That's why it is possible to UNDELETE them, until
such time as DOS uses that particular area of disk space to store some
other file, which overwrites the old deleted file and makes it totally
unrecoverable!





                          The |TDEVICEHIGH|T Command

This does exactly the same thing that the DEVIC|1E command does, only it
loads the specified device into the Upper Memory Blocks instead of into
conventional RAM.  In order for this to work, you have to have DOS ver-
sion 5.0, a 386 or later computer, some extended |nmemory|n, and the proper
statements in your CONFIG.SYS to prepare the UMB for use by DOS.  Here's
a basic |nCONFIG.SYS|n file that will work for this purpose:
          DEVICE=C:\DOS\HIMEM.SYS
          DEVICE=C:\DOS\EMM386.EXE NOEMS
          DOS=HIGH,UMB
          DEVICEHIGH=whatever
You can use the "RAM" parameter in place of the "NOEMS" parameter on the
EMM386 line, if you want to be able to use expanded (|sEMS|s) |nmemory|n.  But of
course it will eat up a bunch of your |nupper|n |nmemory|n, for the |nexpanded|n mem-
ory's page frame.

If you run out of |nupper|n |nmemory|n so that DOS can't load the specified de-
vice there, it will still load the device, but into |nconventional|n |nmemory|n,
                           <page down> for more
                           DEVICEHIGH continued
just as if you had used the DEVIC|1E command instead.

Now there are |sTSR|ss and |sdevice driver|ss that just won't run from Upper Mem-
ory at all.  No matter what.  And there are others that would run there
if only you could get them up there.  Some of them give a MEM command
reading like as if they were small enough to fit into a free UMB, and yet
they will load into conventional RAM instead of loading |nhigh|n, as if there
was not enough memory free in the UMB.  A lot of times, all this means is
that there's not enough |nmemory|n up there for it to load, not that there's
not enough for it to run.  What?  Well you see, many drivers and TSRs re-
quire a whole bunch of |nmemory|n while they're loading, but then as soon as
they're loaded, they settle down and only take up their normal amount of
|nmemory|n.  If you've got one of these, all you have to do is put its com-
mand earlier in the CONFIG.SYS or AUTOEXEC.BAT file, so that it loads be-
fore something else, so that at that time, there is a larger UMB open.
Then it can load, and it will settle down to its normal small size, so
that there will still be room for the one that you put the misbehaving
one in front of.  So with |nDEVICEHIGH|n and LOADHIGH, loading order of TSRs
and device drivers matters even more than it used to before DOS 5.0.
                            The |TDEVIC|1E|T Command

This is a command that only works in your CONFIG.SYS file, and what it
does is load a device driver into memory.  You have to watch what order
you put the DEVICE lines into your |nCONFIG.SYS|n file though.  For example,
any device that wants to use expanded |nmemory|n has to come after the line
that loads your |nexpanded|n |nmemory|n manager.  Any device that is going to use
the mouse has to be loaded into |nmemory|n after the mouse driver loads.

The syntax is quite simple.  Just remember that you have to include the
full file specification, including the path and the filename's extension,
for the |ndevice driver|n you're trying to load.  Since the |nCONFIG.SYS|n file
is read during |sboot|sup before COMMAND.COM loads and AUTOEXEC.BAT gets ex-
ecuted, there is no |nPATH|n variable in the environment yet so DOS can't
find any file that's not in the root directory of the boo|1t disk.  But you
shouldn't keep any device drivers in the |nroot|n |ndirectory|n of a hard disk.
Put them into a subdirectory to keep your |nroot|n |ndirectory|n clean.  A DEVICE
command should look similar to this:
          DEVICE=C:\DOS\ANSI.SYS

                           The |TDISKCOMP|T Command

This command is used to compare the data on one disk to the data on an-
other.  About the only use for it is right after you use the DISKCOPY
command, to make sure that command was completely successful.  Read the
section about the |nDISKCOPY|n command for more information, because the two
commands are quite similar in the way they operate.

Notice that |nDISKCOMP|n will say that two disks are totally different if the
one is not a |nDISKCOPY|n of the other.  Even if they have the exact same
files on them.  Because for example, if the files on the source disk were
fragmented, and the COPY or XCOPY command was used to copy all the files
to another disk, the target disk will be totally unfragmented.  And DISK-
|nCOMP|n compares sector-by-sector, not file-by-file.  So the two |ndisks|n won't
compare at all, even though each file on the target disk might be an ex-
act duplicate of its twin on the source disk.




                              The |TDO|1S|T Command

If you have DOS version 5.0, a 286 or later computer, and some extended
memory, you can put the DOS kernel into the High |nMemory|n Area to free up
about 45K of conventional |nmemory|n.  The command DOS=HIGH, if it is placed
into your CONFIG.SYS file after the HIMEM.SYS device driver is loaded,
will cause that to happen.  This will cause your BUFFERS to be loaded in-
to the HMA as well.

If you have a 386 or higher computer you can use the DOS=HIGH,UMB command
instead of plain old DOS=HIGH, after an expanded |nmemory|n manager such as
|nEMM386|n.EXE is loaded, to enable Upper |nMemory|n Block support so that you
can use the DEVICEHIGH and LOADHIGH commands to place your device drivers
and |sTSR|ss into the UMB area to free up a whole lot more |nconventional|n RAM.

If for some reason you want to have access to the UMB without having the
DOS kernel loaded |nhigh|n, you can use the command DOS=UMB instead.



                              The |TDIR|T Command

This command is used to display a DIRectory listing on your monitor.  A
|ndirectory|n listing includes the name, extension, size, and date and time
of last modification, for each file listed.  It also tells the volume
label of the disk, the name of the |ndirectory|n being listed, the number of
files and subdirectories displayed, and the free space left on the disk.

The |nDIR|n listing does not include files which have their H or S attributes
set to on, but it does work on files with R and A |nattributes|n.

You can display the |ndirectory|n listing for all the files in the current
|ndirectory|n by giving the command |nDIR|n all by itself, with no parameters.
You can see the listing for all the files in some other |ndirectory|n by in-
cluding that |ndirectory|n's |spath|sname on the command line, as in |nDIR|n \DOS.
You can see the entries for the files on a different disk by including
that disk's drive letter as part of the command as in |nDIR|n A:.  You can
see the names of only the files that have a .COM extension, by typing |nDIR|n
.COM, or just the files that start with the letter S by using |nDIR|n S*, or
                           <page down> for more
                               DIR continued
just about anything you want to do by using the * and ? wildcards and/or
the name of the drive and/or directory whose listing you want to display.
(Notice those commas are punctuation in the sentence, not part of the
commands.)  With the |nDIR|n command, you don't have to always include both
the filename and the extension of a group of files.  I mean if you wanted
to do something like copy all the files that have a .COM extension, you
would have to say *.COM but if you just want a |ndirectory|n listing of those
files, .COM will work.  The same way with all the files that start with
S, to copy them you would have to say S*.* but to get a |ndirectory|n listing
of them, S* will work.

If you want to list the files that have no extension, |nDIR|n *. will do it.
If you just said |nDIR|n * then DOS would show you every file, in the speci-
fied |ndirectory|n, even those that have extensions.  But since *. includes a
period, which is what separates filenames from their extensions, and then
it doesn't have anything after the period, that tells |nDIR|n to only show
files that have blank extensions.

                           <page down> for more
                               DIR continued
If you see a line that says <DIR> on it, in a directory listing, that is
a subdirectory entry.  You can see what files are in that subdirectory by
issuing the command |nDIR|n NAME where NAME is the name of that subdirectory.

If you are displaying the listing for any |ndirectory|n other than the root
|ndirectory|n, the first two entries will be . <DIR> and .. <DIR>.  See the
section on ". and .." for an explanation of those lines.

Remember that if you're looking for a particular file, it's a lot easier
to issue the command |nDIR|n FILENAME.EXT or |nDIR|n FILE*.* than it is to just
use the command |nDIR|n and scan all the filenames yourself looking for that
one file.  Let DOS do the work for you.

Although DOS displays the filename, and then one or more blank spaces,
and then the extension, that's not the format you want to use when you're
trying to do something with a file.  When you use a filename in a com-
mand, you type the filename, then no spaces, then the period, then the
extension.  That's the only way you'll get anything done in DOS, even if
                           <page down> for more
                               DIR continued
that's not the way DOS displays the directory listing.  Really, though,
it is more convenient the way DOS displays it.  It's just a lot easier to
read a |ndirectory|n listing like that.  I've seen some file management util-
ities that display |ndirectory|n listings the way they have to be typed, and
they're really hard to read.  Here's the difference:
          How |nDIR|n Displays Them:               How You Have to Type Them:
          COMMAND  COM                         |nCOMMAND.COM|n
          AUTOEXEC BAT                         |nAUTOEXEC.BAT|n
          CONFIG   SYS                         |nCONFIG.SYS|n
          |nDISKCOPY|n COM                         |nDISKCOPY|n.COM
          FORMAT   COM                         FORMAT.COM
          ANSI     SYS                         |nANSI.SYS|n
          |nATTRIB|n   EXE                         |nATTRIB|n.EXE
          SMARTDRV SYS                         |nSMARTDRV.SYS|n

You can use redirection to send the output of the |nDIR|n command to the
printer, with |nDIR|n > |nPRN|n, or to a file, with |nDIR|n > FILE.EXT.  Of course be
aware that if the file already exists, that command will delete every-
                           <page down> for more
                               DIR continued
thing that's already in the file and put the directory listing in place
of it.  If you want to add the |ndirectory|n listing to the end of a file
that already exists, use two > symbols, as in |nDIR|n >> FILE.EXT.

There are also two switches you can use with the |nDIR|n command, to modify
the command's operation a bit.  The /P switch will cause the |nDIR|n command
to only show you one screenful of data and pause, and say "Press any key
to continue. . ." so that you can read what it says before it scrolls off
the screen.  Then when you "Press any key", the next screenful of info is
displayed, etc.

Then there is the /W switch, which will give you a wide display.  It will
not show you the size or date and time of the files, but will just dis-
play the filenames and extensions, in five columns so that if you have a
|ndirectory|n with a whole bunch of files in it, you might be able to see
them all on the screen at once.

If you have a |ndirectory|n that's got even more files than can be displayed
                           <page down> for more
                               DIR continued
on one screen with the /W switch, you can use the /P and /W switches to-
gether, but you should seriously consider dividing those files into two
or more subdirectories instead of leaving them all in one directory.

If you do not have DOS version 5.0, then skip the rest of this section
except just to see what you're missing.  One of the improvements in DOS
5.0 is a whole lot of options for the |nDIR|n command.

First of all, as well as the number of files listed and the free space
remaining on the disk, at the end of the |ndirectory|n listing, the total
number of bytes in the listed files is displayed.

Now the /W switch causes the filenames to be displayed in the form you
have to type them in, such as "CONFIG.SYS" instead of "CONFIG   SYS" the
way it worked in earlier versions.

Let's have a chart of all the new DOS 5.0 |nDIR|n command switches now, be-
fore we get into serious explanations:
                           <page down> for more
                               DIR continued

          /A |nattributes|n                   /O order for sorting
             A archive                       D date and time
             D |ndirectory|n                     E extension
             H hidden                        G group directories together
             R read-only                     N name
             S system                        S size

             /B bare display--(dirname and) filename.ext only

             /L lowercase dirnames and filenames

             /P pause display on each page (all DOS versions)

             /S subdirectories included

             /W wide display--five columns (all DOS versions)

                           <page down> for more
                               DIR continued
The /A switch will cause all filenames to be displayed, even those with
Hidden and System attributes.  Or you could use /AH to display only the
files that have the Hidden attribute set to on.  Or /A-A to show only the
filenames that do not have the A attribute.  Or /AHR to show only the
files that have both the H and the R |nattributes|n.  Or /A-S-D to show only
the files that have neither the S attribute nor the D (|sDirectory|s) attri-
bute.  (That's right, along with the A, H, R, and S |nattributes|n, there is
also the D one, by which DOS tells files and directories apart, and this
can be accessed by DOS 5.0's new |nDIR|n command although the ATTRIB command
still doesn't work with it.)  Or /AH-S to show only the files that have
the H attribute but not the S attribute.

The /O switch tells DOS what order you want the filenames sorted into
each time you see the |ndirectory|n listing.  The sorting doesn't seem to
slow DOS down, so don't be shy about using this switch.  Without this
switch, DOS displays the filenames in the order that their entries happen
to reside in the |ndirectory|n.  With this switch you can display the direc-
tories in alphabetical order followed by the filenames in alpha order
                           <page down> for more
                               DIR continued
(/O), or all the filenames and directory names mixed together in alpha
order (/ON), or reverse alpha order (/O-N), or all the files with no ex-
tensions followed by the |ndirectory|n names followed by the files that have
extensions sorted by extension (/OE), or the /OE display in reverse order
(/O-E), or all the files and directories mixed together and sorted by
date and time, from earlier to later (/OD), or from later to earlier
(/O-D), or all the directories in the order that they exist in the dir-
ectory followed by the filenames sorted by size starting with the small-
est ones (/OS), or the opposite of /OS--files sorted from largest to
smallest followed by the directories in |ndirectory|n order (/O-S), or final-
ly with the directories first in |ndirectory|n order followed by the files in
|ndirectory|n order (/OG), or files first followed by directories, all in
|ndirectory|n order (/O-G).

And of course you can use any combination of those /O switches.  For ex-
ample, my favorite is /OGEN which means display the directories first,
followed by the filenames, and sort the file extensions in alpha order,
and within groups that have the same extension, sort those files by name.
                           <page down> for more
                               DIR continued
(Having the same extension also means all the files that have no exten-
sion, and that includes directory names, so the |ndirectory|n names do also
get sorted in alpha order with that switch.)  The switch combination
/OD-S would mean to sort the files by date and time, but within groups
that have the same date and time, sort those files by size, in reverse
order meaning from largest to smallest.  (If you created all your direc-
tories at the same time, then they will appear together in a group in
this listing, but they won't be sorted in any particular order because
they all have a size of zero.  But if you add an N to that switch com-
bination, making it /OD-SN, then the |ndirectory|n names, or any other group
of files that have matching dates, times, and sizes, will be sorted in
alpha order by name.)

The /S switch tells DOS to show you a |ndirectory|n listing for the specified
|ndirectory|n, followed by the listings for each and every sub|ndirectory|n of
the specified |ndirectory|n, and every subdirectory of those subdirectories,
etc.  If the specified |ndirectory|n is the root, then this will give you
every filename on the entire disk.  If you combine this switch with a
                           <page down> for more
                               DIR continued
filename or a wildcard specification, such as |nDIR|n *.BAT /S, you would
find every file on the disk that has the specified filename.  Or if you
combine the /S with the /A, as in |nDIR|n /AH /S, that will show you every
file on the disk that has its Hidden attribute set to on.

The /B switch just gives you the filename-period-extension, with no vol-
ume label, no total number of bytes, no file sizes or dates, nothing ex-
cept the name, for all the files.  If you combine it with the /A-D switch
to exclude the directory names, this is really useful for creating a
batch file or text file of all the files in a |ndirectory|n.  |nDIR|n /B /A-D >
FILE.BAT will do it automatically.  And if you add the /S switch, you'll
get all the specified files in the specified |ndirectory|n and all of its
subdirectories, and in that case the display will include the full |spath|s-
name for each file listed, so that you will know which file came from
what |ndirectory|n.

The /L switch will convert all the letters in the |ndirectory|n names and
filenames to lowercase.
                           <page down> for more
                               DIR continued
Now another great feature of the DOS 5.0 |nDIR|n command, is that you can set
an environment variable called DIRCMD to tell DOS what switches you want
to use as the default.  Normally the |ndefault|n is no switches, so if you
type |nDIR|n by itself, you get the display that you would get if you hadn't
entered any switches on the command line, right?  Not anymore.  If you
put the line |nSET|n DIRCMD=/OGEN /P into your AUTOEXEC.BAT file, then every
time you issue the |nDIR|n command, DOS will see in the |nenvironment|n that you
want to use the /OGEN and /P switches as the |ndefault|n, and you will get
that display every time.  Now if you want to see, just this once, a dir-
ectory listing that is not sorted in any way, you can enter |nDIR|n /-O to
tell DOS that you want to temporarily ignore the /OGEN switch that you
have as your |ndefault|n in the DIRCMD |nenvironment|n variable.  Of course like
any other |nenvironment|n variable, you can change it at any time by using
the SET command, or by editing the |nSET|n DIRCMD line in your |nAUTOEXEC.BAT|n
file and |sreboot|sing.

Now remember, when DOS 5.0's |nDIR|n command gives you the total number of
bytes used by the files listed, that means how many |nbytes|n, period.  It
has nothing to do with how much space those files occupy on your disks.
                            |TAbout This Program|T

This "book" is dedicated to all the Computer Club members on the Prodigy
Online Service who always made me feel so good, by thanking me so heart-
ily for my help with their DOS problems.  (You know who you are!)  This
is my way of saying "You're welcome!"  And to all those who suggested,
told, or begged me to write this, I hope it meets your expectations.

The text is all my own, of course, but the Hypertext reader you're using
to read this, and the Hypertext compiler I used to put it together, is a
piece of shareware written by Derek Gitelson of Sansaska Systems.

It's really fun to write Hypertext.  Much more fun than just typing on a
word processor, because from the results, you can almost pretend that
you're actually "programming" or something.  Really, if you look at this
file with a browser, you'll see that it's just plain text with a few con-
trol characters like ||t and ||n to tell the compiler which words are to be
used as "targets", and which are to be highlighted as "hotspots" which
take you to the target when you put your cursor on them and hit <Enter>.
                           <page down> for more
                       About This Program continued
Well, once you have the text written and the control characters inserted,
the compiler takes care of all the hard work, doing all the indexing and
everything.  Then all you have to do is proofread it about six hundred
times.  Except for that part, it's fun.

So if you'd like to do a little Hypertext writing yourself, may I recom-
mend Mr. Gitelson's program, HeLPyoURSeLF.  You can probably find it on
your local BBS, or you can fill out his registration form that I've in-
cluded in the documentation for this program, and send the form along
with $20 + $2.50 shipping and handling, to Mr. Gitelson, and he'll send
you a registered copy of his program.  Or, you can just send it to me
along with your order for a registered copy of my "book", and I'll for-
ward it to him immediately.

Special thanks to Derek Gitelson for allowing me to license his Hypertext
program, to Cheryl Palardy for suggesting the title that I finally decid-
ed on, and to my "beta testers" (proofreaders), Chris Alumbaugh of Rock-
ford IL, Roy Patton of Dallas TX, Wayne Strang of Torrance CA, and my
                           <page down> for more
                       About This Program continued
mentor, Stan MacDonald of Omaha NE.

In case you've somehow lost the README.BAT file that came with this pro-
gram, here's how to register.  For this "book", send $20 + $4 for ship-
ping, and $1.30 for 6.5% sales tax if you're in Nebraska, to Kari Jack-
son, 3201 Monroe, Omaha NE, 68107 and tell me what size and density of
disk you need, and whether you want the printable text version as well as
the normal one.  To order the Hypertext compiler, send $20 + $2.50 for
shipping, and $1.40 for 7% sales tax if you're in California, to Sansaska
Systems, 3311 Concord Blvd, Concord CA, 94519 and of course let him know
also what size disk you need.  These prices are |ncurrent|n as of 8/04/91 but
are subject to change in the future.  Mr. Gitelson is offering this pro-
gram at $5 off the normal price, to purchasers of both this "book" and
his Hypertext program, so be sure to let him know that you're ordering it
"through" me so that he knows why you're only sending $20 instead of $25.




                   What Is an Installable |tDevice Driver|t?

The computer needs to have a |ndevice driver|n for all the device|1s that you
want it to be able to deal with.  The monitor, the keyboard, the disk
drives, the printer, the mouse, the modem, the expanded memory board,
these are just some of the devices that get attached to computers (other
than their users).  Well the computer has a lot of built-in device dri-
vers, such as the ones for CON, AUX, and PRN.  Devices that are not used
by all computers at all times need to have a piece of software loaded
during each bootup, that teaches the computer how to deal with these de-
vices.  And these pieces of software are called installable device dri-
vers.

You install a |ndevice driver|n into the computer's |nmemory|n by using a DEVIC|1E
or DEVICEHIGH command in your CONFIG.SYS file before you boot the compu-
ter.  Some of the device drivers that come with DOS are RAMDRIVE.SYS,
ANSI.SYS, DRIVER.SYS, HIMEM.SYS, and SMARTDRV.SYS.  Don't ever even think
about trying to use a file that has the .COM extension with a DEVICE com-
mand!  A file that has the .SYS extension is probably a |ndevice driver|n,
                           <page down> for more
                          Device Driver continued
but any other extension, don't do it unless the book tells you to!

All device drivers use up some of your memory.  Even the ones that have
switches that make them use extended or expanded |nmemory|n.  For example, if
you use the /E switch to put the RAMDRIVE.SYS |ndevice driver|n into |nextended|n
|nmemory|n, it's only the RAMdisk itself that goes into the |nextended|n |nmemory|n.
The |ndevice driver|n, which you could think of as the |nRAMdisk|n's drive con-
troller, is still in conventional |nmemory|n.  It's very small, however.  For
example, mine only uses up 1184 bytes.  It's well worth it.  Most device
drivers take up very small amounts of |nmemory|n.  But if you use a lot of
them all at once, it does add up.  That's why we like to have ways of
putting them into the Upper |nMemory|n Area, such as with DOS version 5.0's
DEVICEHIGH command.






                                |TTrademarks|T

The following products are trademarks, registered trademarks, or copy-
rights of their respective companies:
          PC, XT, AT, PC-DOS, IBM--International Business Machines
          GW-BASIC, MS-DOS, Windows/386--Microsoft
          8086, 8088, |n286|n, |n386|n, 486, 586--Intel
          BROWSE, KEY-FAKE, PC Magazine--Ziff-Davis Publishing
          QRAM, QEMM, VIDRAM, DESQview/386--Quarterdeck Office Systems
          ASK, CAPSLOCK, HIDE, PC/Computing--Ziff-Davis Publishing
          VM/386--Intelligent Graphics
          CompuServe--H&R Block
          ANSI--American National Standards Institute
          Prodigy--Prodigy Services
          Zenith--Zenith Electronics
          Epson--Epson America
          Kaypro--Kaypro
          Hayes--Hayes Microcomputer Products
          WordStar--MicroPro International
                           <page down> for more
                           Trademarks continued
          UNIX--AT&T Bell Laboratories
          SpinRite--Gibson Research
          Norton Utilities--Peter Norton Computing
          PC Tools--Central Point Software
          4DOS--JP Software
          COMPAQ--COMPAQ Computer
          XMS--Lotus Development, Intel, Microsoft, and AST Research
          |nEMS|n, LIM--Lotus Development, Intel, and Microsoft
          PKZIP, PKUNZIP, PKZIPFIX--PKWARE
          TIMEPARK--Alpha Computer Service
          HISTORY--Bryan Higgins
          NANSI--Daniel Kegel
          MARK and RELEASE--TurboPower Software
          EXPLOSIV--Reidar Gresseth and Chris Hook
          ViruScan--McAfee Associates
          HeLPyoURSeLF--Sansaska Systems
          ALIAS, CED, and any other names, are from various other share-
ware/freeware/public domain/commercial software authors.
                           <page down> for more
                           Trademarks continued
If I've left anyone out, it certainly was not intentional, and I hope you
will forgive me, as well as letting me know so that I can correct the
problem in my next upgrade!
















                         PLEASE IGNORE THIS PAGE!
|TSET|T|fSIMPLY1|f
|t". and .."|t|fSIMPLY1|f
|t286|t|fSIMPLY1|f
|t386|t|fSIMPLY1|f
|tANSI.SYS|t|fSIMPLY1|f
|tATTRIB|t|fSIMPLY1|f
|tAUTOEXEC.BAT|t|fSIMPLY1|f
|tAttributes|t|fSIMPLY1|f
|tBACKUP|t|fSIMPLY1|f
|tBBS|t|fSIMPLY1|f
|tCHDIR|t|fSIMPLY1|f
|tCHKDSK|t|fSIMPLY1|f
|tCMOS|t|fSIMPLY1|f
|tCPU|t|fSIMPLY1|f
|tCache|t|fSIMPLY1|f
|tDISKCOPY|t|fSIMPLY1|f
|tDirectory|t|fSIMPLY1|f
|tEMS|t|fSIMPLY1|f
|tEnvironment|t|fSIMPLY1|f
|tExpanded|t|fSIMPLY1|f
|tExtended|t|fSIMPLY1|f
|tHIMEM.SYS|t|fSIMPLY1|f
|tMemory|t|fSIMPLY1|f
|tRAM|t|fSIMPLY1|f
|tRMDIR|t|fSIMPLY1|f
|tShareware|t|fSIMPLY1|f
|tbytes|t|fSIMPLY1|f
|tconventional|t|fSIMPLY1|f
|tcurrent|t|fSIMPLY1|f
|tdefault|t|fSIMPLY1|f
|tdownloading|t|fSIMPLY1|f
|tfragmented|t|fSIMPLY1|f
|thigh|t|fSIMPLY1|f
|toverlay|t|fSIMPLY1|f
|tprotected mode|t|fSIMPLY1|f
|troot|t|fSIMPLY1|f
|tupper|t|fSIMPLY1|f
|TRESTORE|T|fSIMPLY2|f
|tASCII|t|fSIMPLY2|f
|tBoo|1t Disk|t|fSIMPLY2|f
|tDisks|t|fSIMPLY2|f
|tExecutable|t|fSIMPLY2|f
|tParameters|t|fSIMPLY2|f
|tRAMdisk|t|fSIMPLY2|f
|tReplaceable|t|fSIMPLY2|f
|tediting keys|t|fSIMPLY2|f
|TCOMMAN|1D|T|fSIMPLY4|f
|TECHO|T|fSIMPLY4|f
|TEMM386|T|fSIMPLY4|f
|TFC|T|fSIMPLY4|f
|TFIND|T|fSIMPLY4|f
|TGOTO|T|fSIMPLY4|f
|TLOADHIGH|T|fSIMPLY4|f
|TMORE|T|fSIMPLY4|f
|TMEM|T|fSIMPLY5|f
|TMODE|T|fSIMPLY5|f
|TPAUSE|T|fSIMPLY5|f
|TRENAME|T|fSIMPLY5|f
|TSELECT|T|fSIMPLY5|f
|TUNDELETE|T|fSIMPLY5|f
|TVERIFY|T|fSIMPLY5|f
|t*.*|t|fSIMPLY5|f
|tBoot|t|fSIMPLY5|f
|tCOMMAND.COM|t|fSIMPLY5|f
|tReboot|t|fSIMPLY5|f
|tWildcards|t|fSIMPLY5|f
|TPRINT|T|fSIMPLY6|f
|TSUBST|T|fSIMPLY6|f
|TTYPE|T|fSIMPLY6|f
|tCONFIG.SYS|t|fSIMPLY6|f
|tFAT|t|fSIMPLY6|f
|tKeyboard|t|fSIMPLY6|f
|tRedirection|t|fSIMPLY6|f
|tTSR|t|fSIMPLY6|f
|tdecimal|t|fSIMPLY6|f
|thexadecimal|t|fSIMPLY6|f
|TEXIST|T|fSIMPLY5|f
|TXCOPY|T|fSIMPLY2|f
|tBatch File|t|fSIMPLY7|f
|tPROMPT|t|fSIMPLY6|f
|TRAMDRIVE.SYS|T|fSIMPLY2|f
|TSMARTDRV.SYS|T|fSIMPLY4|f
|TDRIVER.SYS|T|fSIMPLY6|f
|TCOMSPEC|T|fSIMPLY1|f